For EFI (extensible firmware interface) based BIOS (basic input/output system), there are some critical and valuable data structures and code that need to persist in a system memory at runtime, such as the S3 boot script table, EFI system table, EFI runtime services, etc. S3 resume functionality of EFI based BIOS is built upon the S3 boot script table. EFI runtime services will be used by an Operating System (OS). Without a protection mechanism, they are vulnerable to attack by the virus running at runtime. As such, the virus that has that EFI specific knowledge can take over control of the system by replacing the EFI S3 boot script or other runtime data, with its own rogue version. Executing this rogue routine will cause severe consequences, including critical end user data leakage.
FIG. 1 is a block diagram illustrating a typical configuration initialization of a platform (e.g., a data processing system). Referring to FIG. 1, in an EFI based environment, the platform is initialized in a phased fashion in the normal boot path 101. There are two phases for the platform initialization: Pre-EFI Initialization (PEI) 102, followed by Driver Execution Environment (DXE) 103. During the PEI phase 102, it initializes the minimum system resources to enable the DXE phase 103. During the DXE phase 103, numerous DXE drivers are executed collectively to initialize the platform into the final pre-boot state OS load 104. The majority of platform initialization is accomplished in the DXE phase 103 as it has much richer resources than the PEI phase 102.
In contrast, in S3 resume boot path 108, in order to achieve high-performance S3 restoration, a mechanism called EFI Boot Script is introduced to avoid executing the DXE phase 110 which is too complicated and time-consuming against the very strict requirement of S3 resume time. The process of the platform initialization can be viewed as a sequence of operations including accessing the I/O, memory, and PCI configuration space, and executing specific microprocessor instructions.
All of the above operations can be represented in EFI boot scripts. As such, the platform initialization can be performed by executing a sequence of EFI boot scripts of script table 107. During a normal boot path 101, the DXE drivers record their platform initialization operations as some boot scripts. Before booting the OS (block 104), all of these boot scripts are organized as a boot script table 107 and the boot script table 107 is copied into an Advanced Configuration and Power Interface (ACPI) Non-Volatile Storage (NVS) memory region 105 which will not be perturbed by the OS at runtime.
When the system wakes up and runs the S3 resume boot path 108, PEI module 109 of a boot script engine is able to execute all of the boot scripts in the boot script table 107 to restore (block 110) the configuration done in the previous DXE phase (e.g., block 103), instead of executing the DXE phase. This mechanism can expedite S3 resume. However, because this mechanism S3 resume highly relies on the boot script table 107 which is stored in the system memory and persists through runtime, the boot script table 107 is vulnerable to attack by viruses during runtime. One EFI boot script named dispatch boot script to perform the processor initialization. Dispatch boot script just records the entry point of a piece of arbitrary code. The action taken on execution of the dispatch boot script is just jumping to the entry point as used to execute the code (e.g., code 112). Code 112 will also be stored into ACPI NVS and persist through runtime. This code may be modified by malevolent code running at the runtime. Thus, by attacking the boot script table 107 and the code to be executed 112 during the execution of the boot scripts, viruses running in runtime environment can easily change S3 resume behavior, thereby taking over the control of the system.